FIG. 1 is a block diagram that illustrates a conventional payment system 100.
The system 100 includes a payment device 102 (which may in some situations be a payment-enabled mobile device that stores a payment card account number and runs a payment applet; other form factors for the payment device, such as a fob, are also possible; also card-shaped payment devices, including payment IC cards and magnetic stripe cards are widely used). The system 100 further includes a reader component 104 associated with a POS (point of sale) terminal 106. In some known manner the reader component 104 is capable of reading the payment card account number and other information from the payment device 102. (Some usages include the term “point of interaction” to include both the point of sale at a retail store, plus card acceptance terminals or the like at premises of service providers, transit system entrance gate terminals, etc.)
The reader component 104 and the POS terminal 106 may be located at the premises of a retail store and operated by a sales associate of the retailer for the purpose of processing retail transactions. The payment device 102 is shown in FIG. 1 to be interacting with the reader component 104 and the POS terminal 106 for the purpose of executing such a transaction.
A computer 108 operated by an acquirer (acquiring financial institution) is also shown as part of the system 100 in FIG. 1. The acquirer computer 108 may operate to receive an authorization request for the transaction from the POS terminal 106. The acquirer computer 108 may route the authorization request via a payment network 110 (sometimes also referred to as a “card network”) to the server computer 112 operated by the issuer of a payment account that is associated with the payment device 102. An authorization response generated by the payment account issuer server computer 112 may be routed back to the POS terminal 106 via the payment network 110 and the acquirer computer 108.
One well known example of a payment network is referred to as the “Banknet” system, and is operated by Mastercard International Incorporated, which is the assignee hereof.
The payment account issuer server computer 112 may be operated by or on behalf of a financial institution (“FI”) that issues payment accounts to individual users and/or other entities. For example, the payment account issuer server computer 112 may perform such functions as (a) receiving and responding to requests for authorization of payment account transactions to be charged to payment accounts issued by the FI; and (b) tracking and storing transactions and maintaining account records.
The components of the system 100 as depicted in FIG. 1 are only those that are needed for processing a single transaction. A typical payment system may process many purchase transactions (including simultaneous transactions) and may include a considerable number of payment account issuers and their computers, a considerable number of acquirers and their computers, and numerous merchants and their POS terminals and associated reader components. The system may also include a very large number of payment account holders, who carry payment devices for initiating payment transactions by presenting an associated payment account number to the reader component of a POS terminal.
A typical payment system like that shown in FIG. 1 may also handle other types of transactions, including online shopping transactions in which the purchaser submits a payment account number and related data to an e-commerce website-hosting computer.
To safeguard the security of payment transactions involving payment-enabled mobile devices, it has been proposed—for at least some transactions—that a CDCVM (consumer device cardholder verification method) process be performed in the payment-enabled mobile device. As is familiar to those who are skilled in the art, “CVM” may be considered a synonym for user authentication. One proposal for CDCVM embraces the so-called “FIDO” (Fast Identity Online) protocol for user authentication. FIDO is well known in general to those who are skilled in the art, but a few salient characteristics of it will now be mentioned. With FIDO, the mobile device user biometrically (e.g., via fingerprint scan) unlocks cryptographic credentials stored in the device. The device verifies the biometric input and executes an authentication process via interaction with a remote authentication server. The remote server verifies the data submitted to it by the mobile device and authorizes a/the payment transaction. With FIDO, the biometric information never leaves the mobile device, which tends to preclude a number of different kinds of attacks, thereby enhancing the security of the user authentication.
One challenge faced with implementing FIDO for a payment-enabled mobile device is that it may sometimes be desired to use the device for a payment transaction in a location or at a time when the payment-enabled mobile device is not online with the remote authentication server. In such cases, a known local CDCVM process could be substituted for the usual FIDO CDCVM process, but that may risk causing confusion to the user due to a difference in the user experience between the FIDO CDCVM process and the local CDCVM process.